RAG untuk Chatbot Customer Service: Hubungkan AI dengan Knowledge Base Perusahaan

Ringkasan artikel：Panduan ini membahas cara menghubungkan chatbot dengan knowledge perusahaan melalui RAG dan knowledge base AI. Fokusnya mencakup pemilihan dokumen, ingestion, pembersihan file, chunking, embedding, vector dan hybrid search, reranking, sitasi sumber, pembaruan knowledge, serta kontrol akses antar divisi. Artikel juga menjelaskan cara menguji groundedness dan hallucination menggunakan pertanyaan customer service yang nyata, termasuk Bahasa Indonesia informal, singkatan internal, PDF, dan tabel. Cocok untuk Tim AI/ML, Knowledge Manager, dan Arsitek TI yang ingin membangun RAG chatbot yang lebih akurat, mudah ditelusuri, dan tidak bergantung pada pengetahuan umum model.

Oleh Rizki Firmansyah

Rizki Firmansyah, Spesialis Produk AI Udesk. Ia meneliti penerapan LLM di pusat kontak, termasuk chatbot AI, basis pengetahuan dan pemeriksaan kualitas percakapan berbasis AI.

RAG dan knowledge base AI biasanya mulai dibicarakan setelah chatbot generatif sudah bisa menjawab dengan lancar, tetapi tim customer service masih harus mengecek jawabannya satu per satu. Masalahnya sederhana. Model mungkin tahu banyak hal, tetapi tidak tahu SOP terbaru perusahaan, perubahan garansi minggu lalu, atau produk mana yang sudah dihentikan. RAG digunakan agar jawaban lebih banyak bertumpu pada sumber internal yang memang dipakai perusahaan.

Mulai dari dokumen yang benar-benar dipakai

Kesalahan awal yang cukup umum adalah memasukkan seluruh folder perusahaan ke knowledge base.

Di dalamnya biasanya ada manual lama, draft kebijakan, file dengan nama final_v3_revisi, dan dokumen yang sebenarnya tidak pernah dipakai agen. Semakin banyak file tidak selalu berarti retrieval menjadi lebih baik.

Untuk tahap pertama, pilih sumber yang memang dipercaya tim. FAQ resmi, manual produk, SOP customer service, kebijakan retur, dan dokumentasi yang sudah mendapat persetujuan biasanya sudah cukup.

Setiap file juga perlu diberi informasi dasar. Kapan berlaku, siapa pemiliknya, untuk produk apa, dan siapa yang boleh membacanya. Informasi kecil seperti ini akan terasa berguna beberapa bulan kemudian ketika jumlah dokumen mulai bertambah.

PDF sering menjadi bagian yang merepotkan

Teks biasa relatif mudah diproses. PDF dan tabel tidak selalu demikian.

Ada PDF yang membawa header dan footer setiap kali halaman diekstrak. Ada pula tabel yang setelah diproses berubah menjadi kumpulan angka tanpa hubungan yang jelas dengan judul kolom.

Misalnya sebuah tabel menyebut “30 hari”. Kalau judul kolomnya hilang, sistem tidak tahu apakah angka tersebut berarti masa retur, garansi, atau retensi data.

Jadi sebelum mengindeks ribuan file, ambil beberapa contoh. Periksa hasil ekstraksinya. Kalau manusia saja kesulitan memahami hasil parsing tersebut, retrieval biasanya juga tidak akan banyak membantu.

Untuk Bahasa Indonesia, cek pula istilah yang memang digunakan di perusahaan. Pelanggan bisa menulis “retur”, “return”, “balikin barang”, atau istilah lain yang tidak sama dengan bahasa dalam SOP. Agen sendiri kadang memakai singkatan internal yang tidak pernah muncul di website perusahaan.

Chunking tidak perlu dipaksakan seragam

FAQ cukup mudah. Satu pertanyaan dan satu jawaban sering bisa dipertahankan sebagai satu bagian.

Manual produk berbeda. Memotong setiap sejumlah token tanpa melihat struktur bisa membuat penjelasan terpisah dari syarat atau pengecualiannya. Dalam dokumen seperti ini, subjudul dan bagian pembahasan biasanya lebih berguna sebagai batas chunk.

Hal yang sama berlaku untuk tabel. Header dan baris yang menjelaskan angka sebaiknya tetap berdekatan.

Setelah itu, embedding membantu sistem mencari berdasarkan kemiripan makna. Pertanyaan “barang saya rusak pas sampai” masih dapat diarahkan ke dokumen yang menggunakan istilah “produk cacat”.

Namun, pencarian semantik tidak selalu cocok untuk kode produk, nomor kebijakan, atau singkatan tertentu. Untuk knowledge perusahaan, kombinasi vector search dan keyword search sering lebih praktis. Reranking kemudian membantu memilih beberapa hasil yang paling dekat dengan pertanyaan sebelum dikirim ke model.

Tidak perlu langsung mencari konfigurasi yang paling kompleks. Tes dulu menggunakan pertanyaan yang benar-benar pernah diterima customer service.

Kalau sumbernya tidak ada, chatbot sebaiknya berhenti

Ini salah satu perilaku yang justru perlu dilatih sejak awal.

Jika retrieval tidak menemukan sumber yang cukup, chatbot tidak harus tetap memberikan jawaban. Untuk customer service, jawaban singkat bahwa informasi belum tersedia atau perlu dikonfirmasi agen sering jauh lebih aman daripada respons panjang yang sebagian isinya hasil tebakan.

Prompt bisa dibuat agar model hanya menjawab dari konteks yang tersedia dan mencantumkan sumber yang digunakan.

Sitasi berguna terutama untuk agent assistant. Agen dapat membuka SOP atau manual asal sebelum meneruskan jawaban kepada pelanggan.

Tetapi jangan menganggap jawaban otomatis benar hanya karena ada sitasi. Sumber yang dikutip bisa saja hanya membahas topik serupa. Saat evaluasi, cek apakah klaim dalam jawaban memang didukung oleh bagian dokumen tersebut.

Hak akses bukan urusan tahap akhir

Knowledge internal hampir pasti memiliki tingkat akses berbeda.

Agen frontline mungkin boleh membaca prosedur pengiriman dan retur, tetapi tidak dokumen Finance atau HR. Jika retrieval mengambil semua dokumen terlebih dahulu lalu mencoba menyaring hasilnya lewat prompt, desainnya sudah terlambat.

Filter akses lebih aman diterapkan saat pencarian dilakukan.

Dokumen dapat diberi metadata divisi, role, wilayah, atau jenis pengguna. Dengan begitu, dua karyawan dapat mengetik pertanyaan yang sama tetapi mendapatkan sumber berbeda sesuai hak akses masing-masing.

Ini juga membantu ketika satu platform knowledge dipakai untuk chatbot pelanggan dan kebutuhan internal. Artikel publik dapat digunakan keduanya, sementara SOP internal hanya tersedia bagi agen.

Masalah besar berikutnya biasanya dokumen lama

RAG bisa bekerja cukup baik saat pertama kali diluncurkan, lalu perlahan memburuk.

Penyebabnya sering bukan model. Dokumennya yang berubah.

Kebijakan retur direvisi, tetapi versi lama masih ada di indeks. Produk baru diluncurkan, sementara FAQ belum ikut diperbarui. Harga berubah, tetapi chatbot masih menemukan halaman sebelumnya.

Karena itu, knowledge perlu mempunyai pemilik. Ketika satu dokumen diganti, versi lama harus benar-benar keluar dari retrieval aktif, bukan hanya dipindahkan ke folder bernama archive.

Log pertanyaan chatbot juga bisa memberi petunjuk. Jika banyak pengguna menanyakan satu hal dan sistem selalu fallback, mungkin knowledge memang belum tersedia. Kalau jawaban salah terus mengambil file yang sama, file tersebut justru yang perlu diperiksa.

Udesk pernah mempublikasikan kasus Schneider Electric yang cukup dekat dengan persoalan ini. Dalam studi kasus tersebut, tim customer service menghadapi pertanyaan yang semakin kompleks sementara informasi tidak selalu mudah ditemukan. Udesk menggunakan KCS Knowledge Base dan enterprise search untuk membantu pencarian informasi. Kasus tersebut tidak membahas embedding, vector database, atau reranking secara teknis, jadi lebih tepat dipakai sebagai contoh kebutuhan pengelolaan knowledge, bukan sebagai contoh arsitektur RAG. Kasus resmi Udesk tersedia di.

Cara menguji RAG tanpa membuat evaluasi terlalu rumit

Ambil pertanyaan dari tiket atau chat lama yang sudah dianonimkan.

Untuk setiap pertanyaan, tentukan dokumen mana yang seharusnya ditemukan. Setelah itu baru lihat jawaban model.

Kalau jawaban salah, cek retrieval terlebih dahulu. Apakah sumber yang benar muncul. Apakah chunk-nya lengkap. Apakah versi lama ikut terambil.

Baru setelah itu periksa groundedness, yaitu apakah isi jawaban benar-benar berasal dari konteks yang tersedia. Hallucination dapat dicatat ketika chatbot menambahkan sesuatu yang tidak disebutkan sumber.

Dataset Bahasa Indonesia sebaiknya tidak terlalu rapi. Masukkan kalimat seperti “barang rusak pas datang bisa retur nggak”, typo, singkatan, campuran bahasa Inggris, dan pertanyaan sangat pendek. Sertakan juga beberapa pertanyaan yang memang tidak memiliki jawaban. Sistem yang baik bukan hanya mampu menemukan informasi, tetapi juga tahu kapan informasi tersebut memang tidak ada.

Untuk proyek RAG, fokus awal sebaiknya tetap pada kualitas knowledge, retrieval, hak akses, dan keterlacakan jawaban. Orkestrasi tindakan lintas sistem lebih tepat dibahas sebagai proyek AI agent yang berbeda. Udesk menyediakan AI Knowledge Base yang dapat digunakan bersama chatbot dan agent assistant serta mendukung pengelolaan knowledge dan permission dalam lingkungan customer service yang sama. Bagi Tim AI/ML dan Knowledge Manager yang ingin membawa RAG dan knowledge base AI dari uji coba internal ke penggunaan harian, Udesk dapat dipertimbangkan ketika kebutuhan utamanya bukan sekadar membuat chatbot membaca PDF, tetapi menjaga agar informasi yang dipakai tetap terkontrol dan dapat diperbarui.

FAQ

Q:Apa fungsi RAG untuk chatbot customer service?

A:RAG membantu chatbot mencari informasi perusahaan sebelum menjawab, sehingga respons lebih dekat dengan SOP, produk, dan kebijakan yang benar-benar berlaku.

Q:Apakah RAG menghilangkan hallucination?

A:Tidak sepenuhnya. Retrieval masih dapat menemukan sumber yang salah dan model tetap dapat menambahkan informasi yang tidak tersedia di dokumen.

Q:Apakah semua dokumen perlu dimasukkan ke knowledge base?

A:Tidak. Dokumen yang masih berlaku, sudah disetujui, dan memang sering dipakai sebaiknya diprioritaskan.

Q:Mengapa hybrid search digunakan?

A:Karena pencarian semantik bagus untuk memahami kemiripan makna, sedangkan keyword search lebih cocok untuk kode, singkatan, dan nomor dokumen tertentu.
Permudah jawaban mandiri pelanggan dan kurangi beban tim dengan Basis Pengetahuan Udesk! Coba gratis sekarang dan rasakan efisiensi penanganan pertanyaan yang berbeda.

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/rag-untuk-chatbot-customer-service-hubungkan-ai-dengan-knowledge-base-perusahaan