Embedding dan Chunking, Kunci Akurasi Chatbot RAG
Ukuran chunk, overlap, metadata, model embedding multibahasa, dan reranking menentukan benar-salahnya jawaban chatbot RAG. Ini cara memilih pengaturannya.
Jawaban singkat
Chatbot RAG sering salah bukan karena modelnya, tetapi karena potongan dokumen yang diambil keliru. Potong dokumen mengikuti struktur aslinya, beri overlap secukupnya, tempelkan metadata, pakai model embedding yang paham bahasa Indonesia, dan tambahkan reranking bila hasil pencarian meleset.
Daftar isi
Chunking adalah proses memotong dokumen menjadi bagian-bagian kecil, sedangkan embedding adalah proses mengubah setiap potongan itu menjadi deretan angka yang mewakili maknanya. Keduanya terjadi jauh sebelum pengguna mengetik pertanyaan, dan keduanya menentukan potongan mana yang nanti diberikan kepada model AI untuk menyusun jawaban.
Taruhannya besar. Bila potongannya terlalu pendek, konteks penting terputus. Bila terlalu panjang, informasi yang dicari tenggelam di antara teks lain. Bila model embedding tidak paham bahasa Indonesia dengan baik, pertanyaan "berapa lama garansi?" bisa gagal menemukan paragraf tentang "masa jaminan produk". Hasil akhirnya sama: chatbot menjawab dengan yakin dari potongan yang salah, dan tim mengira modelnya yang bermasalah.
Bagaimana pengaturan chunking memengaruhi jawaban?
Ada empat keputusan yang saling berkaitan dalam chunking.
Ukuran potongan
Ukuran biasanya dihitung dalam token (kira-kira potongan kata) atau karakter. Potongan kecil membuat pencarian lebih tajam, karena setiap potongan membahas satu hal. Kelemahannya, potongan bisa kehilangan konteks, misalnya kalimat "biayanya gratis untuk paket ini" tanpa menyebut paket yang mana.
Potongan besar membawa lebih banyak konteks, tetapi maknanya menjadi campur aduk. Embedding dari satu halaman penuh yang membahas lima topik akan "rata-rata" dari kelima topik itu, sehingga kurang cocok dengan pertanyaan spesifik.
Titik awal yang banyak dipakai praktisi ada di kisaran beberapa ratus token per potongan. Anggap ini sebagai angka uji pertama, bukan aturan, lalu sesuaikan dari hasil pengujian dengan dokumenmu sendiri.
Overlap
Overlap adalah bagian teks yang diulang di akhir satu potongan dan awal potongan berikutnya. Gunanya mencegah informasi terbelah tepat di batas potongan. Overlap kecil, misalnya sekitar sepersepuluh sampai seperlima ukuran potongan, biasanya cukup. Overlap terlalu besar hanya memboroskan penyimpanan dan membuat hasil pencarian berisi potongan yang hampir sama.
Memotong mengikuti struktur
Cara memotong sering lebih penting daripada ukuran. Memotong buta setiap sekian karakter bisa memisahkan judul dari isinya atau membelah tabel di tengah. Lebih baik memotong mengikuti struktur dokumen: per bagian dengan judulnya, per pertanyaan di FAQ, per pasal di dokumen kebijakan, per baris atau kelompok baris di tabel harga.
Untuk dokumen dengan struktur jelas seperti Markdown atau HTML, banyak pustaka RAG menyediakan pemotong yang mengenali judul. Untuk PDF hasil pindaian, pastikan teksnya terbaca dengan benar sebelum dipotong, karena kesalahan OCR akan terbawa sampai ke jawaban.
Metadata
Setiap potongan sebaiknya membawa keterangan: judul dokumen, judul bagian, tanggal berlaku, divisi pemilik, dan tingkat akses. Metadata dipakai untuk dua hal. Pertama, filter, misalnya hanya mencari di dokumen yang masih berlaku atau yang boleh dilihat penanya. Kedua, konteks, misalnya menempelkan judul dokumen dan bagian di awal teks potongan sebelum dibuat embedding, sehingga potongan "biayanya gratis" tahu ia berasal dari bagian paket mana.
Memilih model embedding dan reranking
Model embedding untuk bahasa Indonesia
Model embedding ada yang khusus bahasa Inggris dan ada yang multibahasa. Untuk dokumen dan pertanyaan berbahasa Indonesia, pilih model yang secara resmi mendukung banyak bahasa. Pilihannya mencakup model embedding dari API penyedia AI besar dan model open-weight multibahasa yang bisa dijalankan sendiri, misalnya keluarga multilingual-E5 atau BGE-M3. Pilihan model yang bisa dijalankan di server sendiri dibahas di model AI open-weight.
Hal yang perlu diperhatikan: dimensi embedding (memengaruhi ukuran penyimpanan dan batas indeks database), batas panjang teks masukan, dan konsistensi. Embedding dari dua model berbeda tidak bisa dicampur. Bila ganti model, semua dokumen harus dibuat ulang embedding-nya. Dampak dimensi pada pilihan database dibahas di vector database untuk RAG.
Uji model dengan pertanyaan nyata yang ditulis seperti pengguna menulis: campuran bahasa, singkatan, dan salah ketik. Model yang bagus di kalimat baku belum tentu bagus di "brp lama garansi hp nya kak".
Reranking
Pencarian vektor cepat, tetapi kadang urutannya kurang tepat. Reranking adalah tahap kedua: sistem mengambil lebih banyak kandidat dari pencarian awal, misalnya 20 sampai 50 potongan, lalu model reranker menilai ulang relevansi setiap potongan terhadap pertanyaan dan mengambil beberapa yang terbaik.
Reranker biasanya lebih akurat daripada perbandingan embedding biasa karena membaca pertanyaan dan potongan sekaligus, tetapi lebih lambat dan menambah biaya per pertanyaan. Karena itu ia hanya dipakai untuk kandidat yang sudah disaring.
| Pengaturan | Bila terlalu kecil atau tidak ada | Bila terlalu besar atau berlebihan | Titik awal yang wajar |
|---|---|---|---|
| Ukuran chunk | Konteks terputus, jawaban setengah | Makna campur aduk, pencarian kurang tajam | Beberapa ratus token, ikuti struktur dokumen |
| Overlap | Informasi terbelah di batas potongan | Hasil pencarian berisi duplikat | Sekitar sepersepuluh sampai seperlima ukuran chunk |
| Metadata | Tidak bisa memfilter, potongan kehilangan konteks | Teks potongan penuh keterangan tidak relevan | Judul dokumen, bagian, tanggal, akses |
| Jumlah potongan ke model | Informasi penting tidak ikut terbaca | Model bingung, biaya token naik | Sedikit potongan terbaik setelah reranking |
| Reranking | Urutan hasil kurang tepat | Lambat dan mahal bila kandidat terlalu banyak | Tambahkan bila hasil uji pencarian masih meleset |
| Pencarian kata kunci | Kode produk dan nama persis sulit ditemukan | Hasil terlalu harfiah | Gabungkan dengan pencarian vektor (hibrida) |
Kapan memilih potongan kecil, kapan potongan besar
Pilih potongan kecil bila dokumenmu berisi banyak fakta pendek yang berdiri sendiri, seperti FAQ, katalog produk, daftar harga, atau glosarium. Pertanyaan pengguna untuk dokumen seperti ini biasanya spesifik, dan satu potongan cukup untuk menjawabnya.
Pilih potongan lebih besar bila dokumenmu berupa penjelasan panjang yang saling bergantung, seperti SOP bertahap, kebijakan dengan banyak pengecualian, atau laporan analisis. Memotongnya terlalu kecil membuat langkah 3 terpisah dari syarat di langkah 1.
Bila dokumenmu campuran, kamu tidak harus memilih satu ukuran. Banyak sistem memotong per jenis dokumen dengan aturan berbeda. Ada juga pola "potongan kecil untuk dicari, potongan besar untuk dibaca": sistem mencari di potongan kecil yang tajam, lalu mengirim bagian induknya yang lebih besar ke model agar konteksnya utuh.
Untuk reranking, tambahkan bila pengujian menunjukkan potongan yang benar sebenarnya ada di hasil pencarian tetapi tidak di urutan atas. Bila potongan yang benar sama sekali tidak muncul, masalahnya ada di chunking atau model embedding, dan reranker tidak akan menolong.
Cara menyusun kumpulan pertanyaan uji dan menilai hasilnya dibahas di cara menguji akurasi chatbot AI. Konsep RAG secara keseluruhan ada di chatbot AI dari dokumen perusahaan.
Pertanyaan yang sering diajukan
Berapa ukuran chunk yang paling baik?
Tidak ada satu angka yang paling baik untuk semua dokumen. Mulailah dari beberapa ratus token yang dipotong mengikuti struktur dokumen, lalu uji dengan pertanyaan nyata. Dokumen FAQ biasanya cocok dengan potongan kecil, SOP panjang dengan potongan lebih besar.
Apakah harus memakai model embedding berbayar?
Tidak. Ada model embedding open-weight multibahasa yang bisa dijalankan di server sendiri. Model dari API penyedia AI lebih praktis karena tidak perlu merawat server, tetapi biayanya dihitung per pemakaian dan dokumen dikirim ke penyedia.
Apakah perlu membuat ulang embedding bila dokumen berubah?
Ya, untuk potongan dari dokumen yang berubah. Simpan penanda versi atau tanggal di metadata agar sistem tahu potongan mana yang perlu diperbarui dan potongan lama mana yang harus dihapus.
Kenapa chatbot tetap salah padahal dokumennya ada?
Penyebab umumnya: potongan yang benar tidak terambil karena chunking atau model embedding kurang cocok, potongan terambil tetapi kalah urutan, atau dokumen itu sendiri berisi informasi yang bertentangan. Periksa potongan apa yang sebenarnya diambil untuk pertanyaan itu sebelum menyalahkan model.
