Kenapa AI Assistant Anda Menjawab Salah dengan Yakin — dan Bagaimana Retrieval Memperbaikinya

Anda membangun asisten internal di atas dokumen Anda sendiri — SOP, katalog produk, kontrak tahun lalu, buku panduan HR. Di demo ia tampak seperti sihir. Lalu seorang staf mengajukan pertanyaan nyata, dan ia menjawab dengan penuh percaya diri — dan salah. Bukan salah versi “saya kurang yakin”. Salah yang lancar, tersusun rapi, bahkan mengutip sebuah kebijakan. Di titik itulah kebanyakan tim kehilangan kepercayaan pada keseluruhannya.

Refleksnya adalah menyalahkan modelnya, jadi orang menggantinya dengan yang lebih besar dan lebih mahal. Nyaris tidak pernah menolong, karena modelnya memang bukan masalahnya. Masalahnya adalah ia disodori halaman yang salah untuk dibaca. Inilah bagian dari “AI di atas dokumen Anda” yang tidak pernah didemokan siapa pun, dan di 2026 justru di sinilah rekayasa yang sebenarnya bekerja.

RAG dalam satu paragraf, dan di mana ia jebol

Cara standar membuat AI menjawab dari dokumen Anda adalah RAG — retrieval-augmented generation. Sebelum model menulis apa pun, sebuah langkah retrieval mencari dokumen Anda, menarik beberapa potongan (chunk) yang paling relevan, lalu menempelkannya ke dalam prompt. Model kemudian menjawab memakai teks itu, bukan data latihannya. Landasi model pada dokumen nyata Anda dan ia punya jauh lebih sedikit alasan untuk mengarang.

Itu janjinya. Jebakannya: semuanya bergantung pada langkah retrieval menyodorkan chunk yang benar — dan pada setup dasar, sering kali tidak. Laporan independen 2026 menaruh tingkat kegagalan retrieval pada pipeline RAG naif di sekitar 40%. Ketika sistem seperti ini memberi jawaban salah, mengada-ada, atau tidak lengkap, akar masalahnya hampir selalu retrieval, bukan generation. Model menjawab pertanyaan dengan sempurna — dari sumber yang salah.

   pertanyaan pengguna
        |
        v
   +------------------+        mata rantai lemah:
   |  RETRIEVAL       |  <---- kalau ini menarik chunk
   |  cari di dokumen |        yang salah, semua sesudahnya
   +------------------+        salah dengan penuh yakin
        |
        v
   +------------------+
   |  model membaca   |
   |  chunk-nya dan   |
   |  menulis jawaban |
   +------------------+
        |
        v
   jawaban lancar -- berlandas apa pun yang disodorkan,
                     benar atau salah

Kenapa retrieval naif meleset

Kebanyakan percobaan pertama hanya memakai “vector search”: tiap chunk teks diubah menjadi sederet angka (embedding) yang menangkap maknanya, dan sistem mengembalikan chunk yang angkanya paling dekat dengan pertanyaan. Idenya memang cerdas, dan ia gagal dalam tiga cara yang biasa.

Chunking memotong jawaban jadi dua. Dokumen dipecah menjadi potongan berukuran tetap — sering 512 token — tanpa memedulikan makna. Pertanyaan dan jawabannya jatuh di chunk berbeda, sebuah tabel terbelah di tengah, dan tak ada satu chunk pun yang memuat gambaran utuh.

Embedding itu lossy. Memampatkan paragraf padat menjadi satu titik di ruang membuang detail. Lebih buruk lagi, vector search diam-diam gagal pada string persis — kode produk, nomor faktur, regulasi spesifik seperti “PP 28/2024”. Minta sebuah SKU dan kemiripan semantik cuma angkat bahu.

Ketidakcocokan kosakata. Staf Anda dan dokumen Anda memakai kata berbeda. Seseorang bertanya “bagaimana menangani burnout karyawan?” sementara SOP yang relevan diarsipkan di bawah “keseimbangan kerja-hidup” — tak ada kata kunci yang sama, jadi pencarian kata kunci murni tak pernah menemukannya, dan vector search murni pun bisa melewatkannya.

Perbaikannya kecil, dan itu rekayasa, bukan sihir

Tak satu pun dari ini butuh model yang lebih besar. Yang dibutuhkan adalah pipeline retrieval yang lebih baik, dan langkah-langkahnya sudah dipahami luas di 2026.

Hybrid search menjalankan pencarian kata kunci (jago pada istilah dan kode persis) dan vector search (jago pada makna) bersamaan, lalu menggabungkan hasilnya. Pada benchmark publik ini menaikkan kualitas retrieval secara berarti — satu ukuran naik dari sekitar 56,7% ke 66,4%, dan presisi dari sekitar 0,68 (kata kunci saja) ke 0,87 (hybrid), lonjakan 28%.

Reranking adalah tambahan dengan daya ungkit tertinggi. Anda menarik 50–100 chunk kandidat secara murah, lalu model kedua yang lebih teliti (cross-encoder reranker) menilai ulang dan menyisakan segelintir terbaik untuk prompt. Peningkatannya besar: presisi retrieval 15–30% lebih baik untuk kurang dari 100 baris kode, dan hybrid-plus-reranking mendarat 25–40% di atas RAG naif.

Chunking yang lebih cerdas memecah berdasarkan struktur — bagian, subjudul, batas tabel — sehingga tiap chunk menjadi unit yang utuh, dan menyisakan sedikit tumpang tindih supaya jawaban yang melintasi batas tetap selamat.

Apa artinya bagi bisnis Indonesia

Misalkan Anda distributor dengan ribuan produk dan tim support yang seharian menjawab pertanyaan yang itu-itu saja soal spesifikasi, stok, dan retur. Asisten yang berlandas dokumen bisa mengambil beban rutin itu — asalkan ia menarik halaman produk yang benar setiap kali. Dengan retrieval naif ia mengacaukan dua SKU yang mirip dan mengutip garansi yang salah; dengan hybrid search dan reranking ia menarik item yang persis, karena kode produk dicocokkan secara harfiah, bukan “kira-kira”.

Dua hal penting di luar akurasi. Pertama, kualitas retrieval membatasi seberapa bagus jawaban yang mungkin — tak ada model, sebesar atau semahal apa pun, yang bisa memperbaiki halaman yang salah. Belanjakan pada pipeline-nya, bukan cuma modelnya. Kedua, setup RAG yang benar bisa menunjukkan dokumen mana asal tiap jawaban. Jejak kutipan itulah yang membuat output bisa diaudit, memungkinkan manusia memverifikasi balasan berisiko tinggi, dan membantu Anda tetap akuntabel di bawah UU PDP ketika dokumen memuat data pribadi.

   sebelum memercayai AI di atas dokumen Anda, tanyakan:

   [ ] apakah retrieval menggabungkan kata kunci + vector search?
   [ ] adakah langkah reranking sebelum model membaca?
   [ ] apakah chunk dipecah berdasarkan makna, bukan ukuran tetap?
   [ ] apakah tiap jawaban menampilkan dokumen sumbernya?
   [ ] sudahkah diuji pada pertanyaan NYATA Anda, bukan demo?

Pelajaran di balik semua ini tidak keren tapi layak diulang: asisten AI di atas dokumen Anda adalah masalah retrieval yang menyamar dengan kostum model bahasa. Jawaban yang lancar itu bagian mudahnya. Menyodorkan halaman yang benar di depan model, setiap kali, itulah pekerjaannya — dan itu rekayasa biasa yang terukur, bukan model yang lebih besar atau lompatan iman.

Kalau Anda sedang membangun asisten di atas dokumen Anda sendiri dan ingin retrieval-nya dikerjakan dengan benar — hybrid search, reranking, evaluasi jujur pada pertanyaan nyata Anda — lihat layanan software engineering kami atau hubungi Bee Mata.