Membangun asisten RAG yang hanya menjawab dari sumbernya: studi kasus Hikam Shughro

Hikam Shughro adalah aplikasi organisasi yang kami bangun untuk Himpunan Keluarga Al-Manshur Shughro: keuangan, iuran, program ngaji, pengadaan, rapat, dan siaran langsung untuk anggota lintas usia, di Android dan iOS. Satu modul paling sering ditanyakan — Maktabah AI, asisten yang menjawab pertanyaan seputar kitab rujukan himpunan.

Artikel ini menjelaskan cara kerjanya, alasan di balik setiap pilihan teknis, dan apa yang bisa dilakukan pola yang sama untuk bisnis yang bekerja dengan banyak dokumen.

Kenapa chatbot biasa tidak bisa dipakai

Model bahasa umum selalu menghasilkan jawaban. Saat tidak tahu, ia menghasilkan jawaban yang terdengar meyakinkan. Untuk materi rujukan, jawaban yakin yang diatasnamakan kitab padahal kitabnya tidak pernah berkata begitu jauh lebih buruk daripada tidak menjawab — kepercayaan pada aplikasi dan pada sumbernya sama-sama rusak.

Karena itu syaratnya ketat sejak awal:

• Menjawab hanya dari kitab rujukan yang disediakan himpunan — bukan dari pengetahuan umum model.
• Menunjukkan asal setiap jawaban, supaya pembaca bisa membuka sumbernya dan memeriksa.
• Mengatakan terus terang jika kitab tidak membahas sebuah pertanyaan, bukan menebak.

Arsitekturnya dalam empat langkah

1. Ingestion. Setiap kitab dipecah menjadi potongan teks mengikuti strukturnya (kitab, bab, pasal). Setiap potongan diubah menjadi embedding — vektor yang menangkap maknanya — lalu disimpan di PostgreSQL dengan pgvector, lengkap dengan referensi sumbernya.
2. Retrieval. Saat anggota bertanya, pertanyaannya diubah menjadi embedding dengan cara yang sama, lalu pencarian cosine similarity mengembalikan potongan yang paling dekat maknanya. Karena yang dicocokkan adalah makna, bukan kata kunci, pertanyaan dengan redaksi berbeda tetap menemukan potongan yang tepat.
3. Jawaban berbasis sumber. Model bahasa hanya menerima potongan hasil retrieval, dengan instruksi untuk menjawab dari potongan itu saja dan menyebutkannya. Model tidak boleh menambal celah dengan apa yang “ia tahu”.
4. Menolak saat ragu. Jika tidak ada potongan yang cukup relevan, asisten menyampaikan bahwa rujukan tidak membahas pertanyaan tersebut. “Tidak ditemukan” yang jelas adalah fitur, bukan kegagalan.

Kenapa pgvector, bukan vector database terpisah

Aplikasinya sudah berjalan di PostgreSQL. Menyimpan embedding di database yang sama berarti satu sistem untuk di-backup, diamankan, dan dipantau; potongan teks dan metadatanya berada dalam transaksi yang sama; dan filter seperti “hanya kitab ini” cukup ditulis dengan SQL biasa. Untuk perpustakaan sebesar ini, vector database khusus hanya menambah biaya dan komponen tanpa menambah kualitas.

Sitasi yang membuat jawaban bisa dipercaya

Setiap potongan membawa referensi sumbernya sejak di-ingest, sehingga sitasi selalu menunjuk ke lokasi nyata di kitab yang nyata. Jawaban ditampilkan bersama sumbernya. Pembaca tidak perlu percaya pada model — mereka bisa memeriksanya sendiri. Dalam praktiknya, inilah yang mengubah fitur AI dari sekadar gimmick menjadi sesuatu yang benar-benar diandalkan.

Pengujian sebelum rilis

Sebelum diluncurkan, asisten diuji dengan daftar pertanyaan yang disepakati. Untuk setiap jawaban kami periksa dua hal: apakah potongan yang dikutip benar-benar sumbernya, dan apakah jawabannya tidak melampaui isi potongan itu. Daftar uji yang sama dipakai untuk menentukan titik di mana asisten memilih menolak daripada menjawab. Tahap inilah yang paling sering dilewati proyek AI, padahal paling menentukan kepercayaan.

Bagian dari aplikasi utuh, bukan chatbot tempelan

Maktabah AI berada di dalam aplikasi Flutter dengan sepuluh modul. Aplikasi yang sama mentranskripsi rekaman rapat dengan Whisper large-v3 dan menyusunnya menjadi notulen terstruktur, memakai login OTP WhatsApp tanpa kata sandi, serta membatasi setiap modul berdasarkan jabatan. AI-nya berguna karena berada di tempat anggota sudah beraktivitas, berdampingan dengan pekerjaan mereka yang lain.

Di mana pola ini cocok untuk bisnis

Organisasi mana pun yang jawabannya tersimpan di dokumen bisa memakai desain yang sama:

• Customer service yang menjawab dari kebijakan dan manual produk Anda, lengkap dengan sumbernya.
• Asisten internal untuk SOP, buku panduan HR, atau dokumen kepatuhan.
• Tim sales yang butuh jawaban akurat dari katalog, daftar harga, dan kontrak.
• Setiap kasus di mana jawaban salah itu mahal, dan “tidak ditemukan” masih bisa diterima.

Pelajaran yang kami bawa

• Mulai dari sumber yang Anda percaya. Kualitas retrieval dibatasi kualitas dokumennya.
• Sitasi membangun kepercayaan lebih cepat daripada klaim akurasi apa pun.
• Menolak lebih baik daripada menebak — rancang itu dengan sengaja.
• Pakai database yang sudah berjalan sampai ada alasan terukur untuk menggantinya.

Aplikasinya bisa Anda lihat di situs resminya dan di portfolio. Kalau tim atau pelanggan Anda terus bertanya hal yang jawabannya ada di dokumen, ceritakan ke kami — kami akan jujur menilai apakah RAG, pencarian biasa, atau otomasi sederhana yang paling tepat.